Finishes the cross-SDK parity debt: cursor pagination on both shells, the two job listings Node never had, and per-task middleware toggles on Java. With #436 merged, nothing on the parity list is left except the items excluded by design (below).

Node listings it never had

listJobsFiltered and listArchived did not exist. Archived was the sharper gap: a terminal job is moved into archived_jobs as it finishes — the live table only ever holds pending/running rows — so a completed job could not be read back at all from this SDK.

Cursor pagination (S12)

Core has had the *_after methods since Tier 2 and Python has surfaced them; neither shell did, so a deep listing paid O(offset).

• Node: listJobsAfter, listJobsFilteredAfter, listArchivedAfter, deadLettersAfter.
• Java: listJobsAfter, listArchivedAfter with a Page<T>.

next_cursor moves into core beside encode_cursor first. It was living in the Python binding, and "a page shorter than the limit is the last one" is part of the cursor contract, not of one shell — leaving it there meant three SDKs writing it three times.

Java middleware toggles

disableMiddleware/enableMiddleware/listDisabledMiddleware, over the existing settings and keyed as the other SDKs key it. Read per invocation like Node rather than cached like Python, so a toggle lands on the next job with no restart.

The chain is resolved once per invocation and reused for before/after/onError. Re-reading between them would let a toggle landing mid-job run after on a middleware whose before never ran — an unbalanced pair authors are entitled to assume cannot happen. There is a test for exactly that.

Decisions worth review

• The SPI methods are default, and they throw. QueueBackend has an implementor outside this module (InMemoryQueueBackend, 64 overrides), so an abstract method breaks it and every downstream backend. They throw rather than return an empty page: a backend that cannot seek would otherwise look like it had reached the last page. The in-memory backend implements them for real — a default-only method is untested API.
• The smoke exercises a paginated call. GraalVM metadata is generated from what actually runs, so a Page<T> the smoke never touches gets no reflection entry and fails under --no-fallback at runtime rather than in CI.
• napi types an Option as optional but hands back null. The shell normalizes: nextCursor is null on the last page, matching the other SDKs. A === undefined check against the raw value would never have fired.
• The disable key format and name derivation live in one place, so the worker that honours the list and the API that writes it cannot drift.

Verification

Every change has a test watched failing with the change removed:

Rust 193 tests across default/postgres/redis/native-async, clippy + fmt clean. Node 413 tests, typecheck + biome clean. Java ./gradlew build (tests + spotless + checkstyle) plus plainJavadocJar, which gates publishing rather than build.

Still open, by design

• list_workflow_runs_after — on the workflow storage trait, reached via wf_storage rather than storage; worth its own change alongside deadLettersAfter for Java.
• Redis dlq:by_task/logs:by_task — blocked on a backfill migration; the index alone would silently miss every pre-upgrade row.
• Workflow run-state CAS (core, not parity); Node webhook KV + SSRF guard (security, not parity).

Summary by CodeRabbit

• New Features
  • Added keyset/cursor-based pagination for live jobs, archived jobs, and dead-letter entries across the Node.js and Java SDKs.
  • Introduced paginated result models with nextCursor, plus richer job filtering (status/queue/task, metadata/error substring matching, and created-at ranges).
  • Added Java and Node APIs to disable/enable and inspect per-task middleware, including pagination-capable listing endpoints.
• Bug Fixes
  • Malformed pagination cursors are now rejected with clear errors instead of restarting pagination.